I can't find any documentation about this, only:
When two components in the same geometry have an attribute with the same name, the attribute on the “lower level” of geometry is used:
Vertex attributes override:
Point attributes, which override:
Primitive attributes, which override:
Detail (whole geometry) attributes
No mention about P or N being special? It's also not very Houdini style to have special cases like this.. strange!
Found 222 posts.
Search results Show results as topic list.
Houdini Lounge » Changed Normal SOP behaviour?
- Jonathan de Blok
- 253 posts
- Offline
Houdini Lounge » Changed Normal SOP behaviour?
- Jonathan de Blok
- 253 posts
- Offline
Before I put in a bug report, is it me or is a normal sop node deleting any preexisting N attributes even when it's applying normals to another class?
1) add a 'normal' node to some geometry, set it so it adds normals to points.
2) check geoSpreadsheet to assert we have point normals
3) add another 'normal' node below the previous one, set it to add normals to 'prims'
4) check geoSpreadsheet to see prims now do have normals but the point normals are gone.
Easy to workaround, but I don't remember running into this before in the first place?
1) add a 'normal' node to some geometry, set it so it adds normals to points.
2) check geoSpreadsheet to assert we have point normals
3) add another 'normal' node below the previous one, set it to add normals to 'prims'
4) check geoSpreadsheet to see prims now do have normals but the point normals are gone.
Easy to workaround, but I don't remember running into this before in the first place?
Solaris and Karma » what has your experience with solaris/karma been?
- Jonathan de Blok
- 253 posts
- Offline
I also see great potential here but it's no replacement for /obj. As been noticed by others here doing animations in Solaris is a none starter due to unmanageable recooks and what not. Which in turn forces me to jump through the translate-to-USD hoops to be able to use Karma at all. Which creates other problems on its own.
And while the Karma render itself is great the UX is terrible imho, lack of a proper VFB (visual frame buffer) and everything being tied to volitile viewports makes it hard to use. Render Gallery could use a lot of work! The clones are brilliant but should be more control and all AOVs should transfer from them. Also the elusive missing 'render' button is still a mystery to me
Light mixer also great but a hit crashy at times.
So awesome potential here, it just needs to be unlocked better!
And while the Karma render itself is great the UX is terrible imho, lack of a proper VFB (visual frame buffer) and everything being tied to volitile viewports makes it hard to use. Render Gallery could use a lot of work! The clones are brilliant but should be more control and all AOVs should transfer from them. Also the elusive missing 'render' button is still a mystery to me
Light mixer also great but a hit crashy at times.
So awesome potential here, it just needs to be unlocked better!
Solaris and Karma » Render gallery can't save when using linux
- Jonathan de Blok
- 253 posts
- Offline
https://www.sidefx.com/docs/houdini/ref/panes/rendergallery.html#storage [www.sidefx.com]
You can control the path where the gallery saves/loads it data from.
You can control the path where the gallery saves/loads it data from.
Technical Discussion » H20 Viewport refresh bug..
- Jonathan de Blok
- 253 posts
- Offline
This is getting a bit out of hand.. atm I have to reset the viewport every time in dive in/emerge from a node.
The lab's 'reset viewport' helps but no. Is there any info on this, a way to avoid it, workaround or something?
The lab's 'reset viewport' helps but no. Is there any info on this, a way to avoid it, workaround or something?
Solaris and Karma » Houdini 20 - OCIO - ACES 1.2
- Jonathan de Blok
- 253 posts
- Offline
Besides that, in another topic here it was mentioned that some OCIO related fixes in H20 resulted in H20/H19 rendering slight different with identical setups.
Solaris and Karma » interactive rendering with Karma workflow?
- Jonathan de Blok
- 253 posts
- Offline
I guess this is the post you're referring to: https://www.sidefx.com/forum/topic/94172/ [www.sidefx.com]
And +1 for Jason's point, it's one those things you just expect to be there. Max/Maya with V-Ray have had years to develop a VFB and workflow that was comfortable and efficient. It also helped that one of their main purpose is to actually output renders. Doing Houdini renders was, at least in my experience, mostly done when it was to much hassle to export it to other packages or some funky attribute driven contraptions make it impractical to do so. So yeah some catch-up in UX is expected here and I do hope we can have a topic here about plans/feedback before they are put into action so we don't get end up with an API-with-buttons v2.0
And +1 for Jason's point, it's one those things you just expect to be there. Max/Maya with V-Ray have had years to develop a VFB and workflow that was comfortable and efficient. It also helped that one of their main purpose is to actually output renders. Doing Houdini renders was, at least in my experience, mostly done when it was to much hassle to export it to other packages or some funky attribute driven contraptions make it impractical to do so. So yeah some catch-up in UX is expected here and I do hope we can have a topic here about plans/feedback before they are put into action so we don't get end up with an API-with-buttons v2.0
Edited by Jonathan de Blok - 2024年3月12日 08:08:09
Solaris and Karma » Karma ROP default LopNet override and camera inclusions
- Jonathan de Blok
- 253 posts
- Offline
The 'Karma Viewport' button is hardcoded to load the lopnet from the Karma ROP itself, it would be nice if it took the lopnet that's set in the rop_usdrender's 'LOP Path' parm. In the screenshot I've altered the Karma ROP to render out a different lopnet, and while that works, it doesn't translate into the UI. The Karma viewport will always open at the default lopnet. And it would be great if that parm is then also promoted the Karma ROP's interface with a checkbox to override the default internal LOP net.
Why? Well this would allow for the use of custom(ized) lopnets while using the relative comfort of the Karma ROP. For example I have a setup where I fetch the default lopnet's output into a new lopnet and modify it in a few ways. With the above suggestion I could do that without having to alter the default Karma ROP HDA.
Another one is that only the camera that is set in the karma rop is added to the USD stage, making it hard to quickly switch shots in a karma viewport and clone panel. In the customized lopnet I just merge in all cams and it's good. But I guess it's quite a common thing to have multiple cams so maybe a checkbox to force all cameras in there would be a good thing.
Why? Well this would allow for the use of custom(ized) lopnets while using the relative comfort of the Karma ROP. For example I have a setup where I fetch the default lopnet's output into a new lopnet and modify it in a few ways. With the above suggestion I could do that without having to alter the default Karma ROP HDA.
Another one is that only the camera that is set in the karma rop is added to the USD stage, making it hard to quickly switch shots in a karma viewport and clone panel. In the customized lopnet I just merge in all cams and it's good. But I guess it's quite a common thing to have multiple cams so maybe a checkbox to force all cameras in there would be a good thing.
Edited by Jonathan de Blok - 2024年3月7日 07:26:59
Solaris and Karma » What to expect going forward with Solaris?
- Jonathan de Blok
- 253 posts
- Offline
robp_sidefxantc
the granularity of the change tracking is no where near fine enough
There are places in Solaris where we're (reasonably) clever about minimising the frequency/impact of recooking, but it is fair to say we generally are still recalculating a lot more often than should be necessary. It is something we try to continually invest in, and certainly invite everyone to shout at us loudly regarding what they see as the worst offenders.
I was thinking (and I'm sure you guys did too ) but just to float the idea.. would an APEX like approach make things much faster for USD? So basically a scheme where the USD nodes only add things to a 'todo' list, which gets optimized/pruned etc and only executed at the end and/or at nodes that have some sort of 'force execute' flag enabled.
Houdini Lounge » Simple Rendering Question
- Jonathan de Blok
- 253 posts
- Offline
You can add multiple render products so you can add all the resolutions you might need, then render one of those.
I'm not really familiar with the specifics but I've came across this somewhere.
I'm not really familiar with the specifics but I've came across this somewhere.
Solaris and Karma » "Render All Frames with a Single Process"
- Jonathan de Blok
- 253 posts
- Offline
Thanks for the insights! So if it will be 99% fine for Karma ROP users to enable it and get a great speed improvement it might be worth considering checking it by default?
If you have frames that render for 30 minutes a piece it doesn't really matter but if I rarely have scenes that go over a minute per frame and then all the fluffy bits starts to make an impact. And Just curious, do you guys also do performance test with simple spinning cube scenes? If not please consider it, rendering 2000 frames with 5 seconds of actual rendering and 20 seconds of prep per frame really really hurts!
If you have frames that render for 30 minutes a piece it doesn't really matter but if I rarely have scenes that go over a minute per frame and then all the fluffy bits starts to make an impact. And Just curious, do you guys also do performance test with simple spinning cube scenes? If not please consider it, rendering 2000 frames with 5 seconds of actual rendering and 20 seconds of prep per frame really really hurts!
Solaris and Karma » "Render All Frames with a Single Process"
- Jonathan de Blok
- 253 posts
- Offline
The Karma ROP has a checkbox which is labeled "Render All Frames with a Single Process". What exactly does it do under the hood?
When checked it renders out my frame sequence in 4 seconds per frame, unchecked it's around 20 seconds per frame, so why is this unchecked by default? Any drawbacks or situations where using this is a bad idea?
Documentation
"Render all frames in a background process. Default is off. This allows continued interaction with Houdini while the render process runs.
To render multiple frames, the render process renders an image then advances the time on the scene and renders the next image (just like how the Solaris viewport plays back animation). If there is a lot of data shared between frames, this can render significantly faster compared to rendering a single frame per process."
When checked it renders out my frame sequence in 4 seconds per frame, unchecked it's around 20 seconds per frame, so why is this unchecked by default? Any drawbacks or situations where using this is a bad idea?
Edited by Jonathan de Blok - 2024年2月29日 02:45:19
Solaris and Karma » Karma OCIO file rules in XPU and differences between h19 and
- Jonathan de Blok
- 253 posts
- Offline
Maybe it's a good idea to leverage PDG to render out a big set of all sorts of combinations. Assemble them into a mosaic so it's easy to compare outputs from different Houdini versions and flag any errors and such.
In the old days there was a thing called the ACID test which showed any issues in how CSS edge cases where handled by different browsers, was quite interesting. I can envision something similar for OCIO.
In the old days there was a thing called the ACID test which showed any issues in how CSS edge cases where handled by different browsers, was quite interesting. I can envision something similar for OCIO.
Edited by Jonathan de Blok - 2024年2月29日 02:48:09
Solaris and Karma » What to expect going forward with Solaris?
- Jonathan de Blok
- 253 posts
- Offline
Thanks for the translator!
I use path nodes to create some simple animated electronic cables. Paths basically are like rigged bezier curves where you can parent the control nulls to powerplugs and other equipment. Works surprisingly well for these kind of things!
I use path nodes to create some simple animated electronic cables. Paths basically are like rigged bezier curves where you can parent the control nulls to powerplugs and other equipment. Works surprisingly well for these kind of things!
Solaris and Karma » What to expect going forward with Solaris?
- Jonathan de Blok
- 253 posts
- Offline
Ok, well then just make it all a lot faster so there is no need to bypass USD in the first place
But seriously, if I animated 25 individual boxes in /obj and open up the Karma ROP node it plays back at +-20fps at the candidate SceneImport node and around 10 at the end of the Karma ROP graph. I'm not really convinced that that is as fast as it can possibly be. The animated transforms trigger a recook of nearly the entire Karma ROP graph and why the scene import node is choking on this I do not even dare to guess!
I guess I'm not telling anything new here, just want to express my concern for the entire /obj->Karma workflow.
(btw: the Karma ROP doesn't like /obj level path nodes. Draw a path, add a sweep to turn it into a tube.. doesn't translate into USD. Copy the path node's content into a geometry node and it does render.)
But seriously, if I animated 25 individual boxes in /obj and open up the Karma ROP node it plays back at +-20fps at the candidate SceneImport node and around 10 at the end of the Karma ROP graph. I'm not really convinced that that is as fast as it can possibly be. The animated transforms trigger a recook of nearly the entire Karma ROP graph and why the scene import node is choking on this I do not even dare to guess!
I guess I'm not telling anything new here, just want to express my concern for the entire /obj->Karma workflow.
(btw: the Karma ROP doesn't like /obj level path nodes. Draw a path, add a sweep to turn it into a tube.. doesn't translate into USD. Copy the path node's content into a geometry node and it does render.)
Solaris and Karma » What to expect going forward with Solaris?
- Jonathan de Blok
- 253 posts
- Offline
mtucker
I hear this sentiment expressed every now and then, but to be clear, neither Solaris nor Karma would exist without USD. The amount of infrastructure provided by USD and hydra is absolutely enormous. They can't simply be "replaced with native Houdini"
Yeah, it's clear that USD brings a lot of tech to the table and it's obviously a sound decision to take that route for Solaris, that's all fine and good. The "Karma without USD" sentiment is not so much a technical issue, it comes from the UX when you simply want to dial in some materials and render from /obj using Karma. I know you guys take your feedback seriously and I might have been a bit frustrated when I wrote the OP, it's just that I see all these great ingredients but the final dish is slightly undercooked and missing a pinch of salt!
Anyways, just thinking out of the box.. technically it should be doable to skip the USD intermediary and go directly from /obj to Hydra primitives and feed that into Karma. I'm probably oversimplifying thing a bit but If for example the SDK's obj-level GeometryNode's class gets a method to return Hydra primitive data directly that should work just fine to render /obj as-is in any Hydra delegate. It should open the door to much more efficient way into Karma for 'simple' usage since it would know what to recook and what not using all the existing time-dependency and caching code that's already in native Houdini. It's only a hand full of base classes that would need this (geo, light, cam, volume) Not sure about materials but they should carry over quite easily.
That would basically create the option to choose between a performant no-fancy-pants-render-as-is and an all-you-can-eat-USD path without compromising each other. Once that works maybe blur those lines a bit and carry over some requested features.
Edited by Jonathan de Blok - 2024年2月28日 03:49:27
Solaris and Karma » What to expect going forward with Solaris?
- Jonathan de Blok
- 253 posts
- Offline
I'm a bit on a crossroad here on if I want to use Solaris/Karma or go back to RedShift.. This is 3th or 4th time since it's inception that I tried really to make Solaris/Karma work for me and after the occasional sparks of hope I keep running into it's shortcomings. Performance, stability, workflow and overal design and implementation are all tripping over each other and the result is me trying to find the words to not turn this into a rant about what a convoluted mess it is.
All I want is to use Karma as a nice render engine for Houdini without all the USD drama getting in the way. Translating native Houdini on the fly into USD will always be a bottle neck. USD in general isn't a performant design, it's made for handling massive Pixar style scenes using cached out animations and instancing techniques .Everything turns in to thick mud with all the overhead and workflow issues, so much so it's removing Karma from the viable options list for using it as a 'normal' render engine for small shop stuff which a shame because it's actually quite nice.
Is this just me? What are the thoughts here? Ideally I'd like to see a native Karma that doesn't rely on USD. Not hiding USD from view but really rendering native Houdini content like Mantra use to do.
All I want is to use Karma as a nice render engine for Houdini without all the USD drama getting in the way. Translating native Houdini on the fly into USD will always be a bottle neck. USD in general isn't a performant design, it's made for handling massive Pixar style scenes using cached out animations and instancing techniques .Everything turns in to thick mud with all the overhead and workflow issues, so much so it's removing Karma from the viable options list for using it as a 'normal' render engine for small shop stuff which a shame because it's actually quite nice.
Is this just me? What are the thoughts here? Ideally I'd like to see a native Karma that doesn't rely on USD. Not hiding USD from view but really rendering native Houdini content like Mantra use to do.
Edited by Jonathan de Blok - 2024年2月27日 10:25:18
Solaris and Karma » FailRenderException : Error: Accessed invalid null prim
- Jonathan de Blok
- 253 posts
- Offline
Nevermind, it was my bad. I had an 'open' karma rop where something broke during an update to a newer Houdini version.
Solaris and Karma » FailRenderException : Error: Accessed invalid null prim
- Jonathan de Blok
- 253 posts
- Offline
Getting a "FailRenderException : Error: Accessed invalid null prim" from the translator:
Anyone ran into this before? Works fine when rendered in Houdini, fails with deadline on same machine.
2024-02-27 07:59:26: 0: STDOUT: Traceback (most recent call last):
2024-02-27 07:59:26: 0: STDOUT: File "C:/PROGRA~1/SIDEEF~1/Houdini 20.0.625/houdini/husdplugins\objtranslators\base.py", line 43, in populatePrim
2024-02-27 07:59:26: 0: STDOUT: prim.SetActive(False)
Anyone ran into this before? Works fine when rendered in Houdini, fails with deadline on same machine.
Technical Discussion » Auto generate render previews with multiple HDRis
- Jonathan de Blok
- 253 posts
- Offline
-
- Quick Links